Add trace level logging to most API entry points #4183
Conversation
|
I didn't format many of the arguments in the log (mostly the ID of the object in question) in this PR, We should probably format more arguments (the descriptors may be a bit much but there's a fair amount of other useful info) Let me know what you think. I also didn't add much logging to the error paths, I can add them in this PR or a followup. |
|
indeed! |
There was a problem hiding this comment.
LGTM!
The use case I can imagine for the additions specifically appears to be adding context for other log messages. This sort of context-keeping is very similar in domain to tracing's "span"-based model. I wonder if this might be worth exploring for wgpu later; it might obviate things like this PR later, and avoid pitfalls when multiple threads are involved (which I think we do for wgpu right now?).
EDIT: olol, @teoxoy beat me to approval. 😆
|
My main motivation right now is to easily inspect what failing webgpu pages do in firefox's about:logging. If we can get that with spans then 👍 |
|
Did wgpu ever compile-out its logs with a cargo feature? In the past, Bevy has noted that a significant amount of time is wasted in wgpu checking if logs are enabled or not at runtime: bevyengine/bevy#7223. I can't find an issue or PR about it in this repo though. |
|
If you depend on the log crate with a feature flag like |
Checklist
cargo clippy.Description
This PR adds trace-level logs to all or most of the entry points in wgpu-core. A fair amount of debug level logs were converted to trace in the process.